Skip to content

UID2-7505: Point v2 envelope error responses to encryption/decryption docs#2657

Open
sunnywu wants to merge 1 commit into
mainfrom
syw-UID2-7505-descriptive-envelope-errors
Open

UID2-7505: Point v2 envelope error responses to encryption/decryption docs#2657
sunnywu wants to merge 1 commit into
mainfrom
syw-UID2-7505-descriptive-envelope-errors

Conversation

@sunnywu

@sunnywu sunnywu commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Summary

Makes the v2 request-envelope parse errors in V2RequestUtil self-explanatory so callers who send an unencrypted body (e.g. a raw curl request with base64-encoded JSON) understand that the body must be an encrypted request envelope.

Private Operator customers repeatedly call /v2/token/generate directly with:

curl -X POST ".../v2/token/generate" \
  -H "Authorization: Bearer <key>" -H "X-UID2-Client-Secret: <secret>" \
  -d "$(echo -n '{"email_hash":"...","version":2}' | base64 -w 0)"

Because the body is base64 of plain JSON (not an encrypted v2 envelope), byte 0 fails the version check and the operator returns the opaque:

{"message":"Invalid body: Version mismatch.","status":"client_error"}

Nothing in that message tells the caller the real problem is that the payload must be encrypted. In a recent support thread this caused days of back-and-forth — the customer kept re-running curl-with-base64 tests, got "Version mismatch" each time, and mistook it for a server-side bug.

Change

Appends a hint to the three envelope-parse errors that fire when the body is not a valid encrypted envelope:

  • Invalid body: Body too short. Check encryption method.
  • Invalid body: Version mismatch.
  • Invalid body: Check encryption key (ClientSecret)

The hint tells the caller the body must be an encrypted request envelope (base64-encoding JSON is not enough) and links to https://unifiedid.com/docs/getting-started/gs-encryption-decryption#encryption-and-decryption-code-examples.

The existing leading phrase of each message is preserved, so any downstream code that pattern-matches on the current text is unaffected.

Testing

  • Updated testParseRequestWithTooShortBody to assert the leading phrase (via startsWith) plus the presence of the docs link.
  • Added testParseRequestWithVersionMismatch, which feeds base64 of plain JSON (the exact curl failure mode) and asserts both the preserved Invalid body: Version mismatch. prefix and the docs link.
  • mvn -Dtest=V2RequestUtilTest testTests run: 7, Failures: 0, Errors: 0.

Jira

UID2-7505

🤖 Generated with Claude Code

… docs

The v2 request-envelope parse errors ("Version mismatch", "Body too
short", "Check encryption key") gave callers no hint that the body must
be an encrypted request envelope rather than base64-encoded plain JSON.
Private Operator customers hitting the endpoint with a raw curl call
(base64 of JSON) repeatedly got the opaque "Invalid body: Version
mismatch." and mistook it for a server-side bug.

Append a hint to these three envelope errors explaining that the body
must be encrypted and linking to the encryption/decryption code
examples. The leading machine-readable phrase is preserved so any
downstream pattern-matching is unaffected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Ticket: UID2-7505
Branch: syw-UID2-7505-descriptive-envelope-errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant